The present disclosure relates generally to the field of computer systems for optimizing the latest a user-defined class loader.
A typical enterprise Java application generally has a server servicing many clients. A banking application is a good example to illustrate the fact that a server can have hundreds of clients connecting to it. A customer, considered a client application here, will make transactions on his/her account. These transactions require data to be exchanged between the client and server.
Distributed computing in JAVA makes use of either RMI-JRMP or RMI-IIOP technologies. Java Remote Method Protocol or JRMP is a Java-specific, stream-based protocol for Java-to-Java remote calls, requiring both clients and server to use Java objects. On the other hand, RMI-IIOP denotes the Java Remote Method Invocation (RMI) interface over the Internet Inter-Orb Protocol (HOP), which delivers Common Object Request Broker Architecture (CORBA) distributed computing capabilities to the Java platform. CORBA is a standard defined by the Object Management Group (OMG) designed to facilitate the communication of systems that are deployed on diverse platforms. With features inherited from CORBA, software components that work together can be written in different languages (for example, C++ and Java). Both RMI-JRMP and RMI-IIOP leverage JAVA serialization to communicate (transfer parameters) between components. A Java object is serializable if its class or any of its superclasses implements either the java.io.Serializable interface or its sub interface, java.io.Externalizable.
Marshaling (involves serialization) is a process of decomposing an instantiated object into a data format that may be transferred via a message. Un-marshaling, is a process of reconstructing an instantiated object at a receiving device in response to receipt of a message including an object formatted as serialized/marshaled data. During an un-marshaling (involves de-serialization), a new instance of an object is created from a serialized data object, such as a serialized data object received within a message. As such, at least one corresponding class associated with the object has to be loaded if not already loaded. Certain of the non-limiting examples described herein refer to the CORBA architecture and specification. The CORBA specification typically mandates that the class loading, at first, should be attempted using the Latest User Defined Class Loader (hereafter abbreviated as LUDCL).
Obtaining the LUDCL for a particular thread is performed by invocation of certain virtual machine application programming interfaces (APIs) and this occurs during every de-serialization of a CORBA message. Using an example of several enterprise applications, extensive CPU time is spent in the JVM/JIT procedures that assist in thread stack walk to identify the LUDCL.
LUDCL is typically needed to be computed for every object that is unmarshalled. In the existing ORB implementation the computed LUDCL is cached and reused to unmarshal the entire object graph (Various fields of the object) to save the cost provided the object is non-custom marshal. There are scenarios (Custom Marshal Scenarios) in de-marshalling where the program execution goes out of the JDK/CORBA source code into the application code and returns to the JDK/CORBA source code. When the control goes to the application, the application is free to invoke any method (and hence create a stack frame on the current thread stack) whose class is loaded by a different user-defined class loader. This changes the LUDCL and hence one cannot use the cached one in the case of Custom marshal payload scenarios. Such a transition between user-defined class loaders occur with or without intervening bootstrap loader method invocations. This demands the LUDCL to be computed for each object that are unmarshalled in the given object graph.